NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/613

Internet Message Format | 1996-08-06 | 3.6 KB

Path: mail2news.demon.co.uk!genesis.demon.co.uk
From: Lawrence Kirby <[e-mail]>
Newsgroups: comp.std.c
Subject: Re: Paradox due to A7.1 Pointer generation rule
Date: Wed, 20 Mar 96 22:32:04 GMT
Organization: none
Message-ID: <[e-mail]>
References: <4ikp70$[e-mail]>
Reply-To: [e-mail]
X-NNTP-Posting-Host: genesis.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
X-Mail2News-Path: genesis.demon.co.uk

In article <4ikp70$[e-mail]>
           [e-mail] "Vishv Malhotra" writes:

>
>In the following function a++; is acceptable but b++; is not.
>
>        void foo(int a[20]) {
>                int b[20];
>
>                a++;
>                b++;
>        }
>
>I understand the reason, but I wish to know if there is any thought
>on elimination the anomaly?

That would gratuitously break existing code for no practical gain.

You refer in the subject line to A7.1 which in K&R describes how in an
expression an array evaluates to a non-lvalue pointer to its first element.
That explains why b++ is illegal (since ++ requires its operand to be an
lvalue) but is not relevant to a. That is because a declaration is not an
expression and a different rule (commonly called the rewrite rule) applies
to function parameters. In essence a parameter of type array of T is
rewritten to have type pointer to T. So the definition of foo() above means
precisely the same thing as one defined as:

         void foo(int *a) {
           ...
         }

Clearly this mirrors the rule for array evaluation (and there is a similar
case for functions/function pointers) but the rewrite rule affects the
fundamental type of an object rather than just the value derived from it.
In a++ in the code above ++ is genuinely being applied to a pointer object
and, for example, sizeof a == sizeof(int *). a really is a pointer whereas
b is not.

I suppose you could eliminate the rewrite rule for arrays but I don't
think that would be helpful. It would also generate as many anomalies as
it eliminates.

>Perhaps, I should state my problem more clearly, in K&R on page 115
>where command line arguments are being explained the diagram for argv
>corresponds to the declaration
>
>        char *(*argv)[]

No, it corresponds to:

         char **

'Pointer to an array' tends to be used rather loosely to mean 'pointer to
an element (usually the first) of an array'. The point is that once you
can address one element of an array you can address all of the others using
pointer arithmetic so, for instance when you have:

    int a[10];
    int *i = a;

you can use i to address any element of a. Some (including K&R seemingly)
say that i points to array a. IMHO this is a poor description but it is a
usage you have to be aware of.

>I have never seen such a declaration! Nor does this seem to work on
>my compiler. Is the diagram on page 115 not true representation of
>ANSI C standard?

I think the arrow from argv should point inside the the box that represents
the array to the first element, not just at the box itself. K&R is really
just following diagramatically the loose usage of terminology.

Note that unless your question is directly relevant to the contents of
the ANSI/ISO C standard document rather than the C language in general you
should post it to comp.lang.c or comp.lang.c.moderated. K&R no longer
holds the position of language standard (not even the appendices).

--
-----------------------------------------
Lawrence Kirby | [e-mail]
Wilts, England | [e-mail]
-----------------------------------------